In a wireless communications network radio terminals communicate with one or more Core Networks (CNs) via one or more Radio Access Network(s) (RAN).
The radio terminals may e.g. be a mobile station (MS) or a user equipment (UE) or similar wireless device, e.g. such as mobile phones, or cellular phones, or laptops or similar devices with wireless capability, and thus can be, for example, portable, pocket, hand-held, computer-comprised, or vehicle-mounted wireless or other wireless devices which communicate voice and/or data with a radio access network.
The Radio Access Network (RAN) covers a geographical area which is divided into cell areas, with each cell area being served by a base station, e.g. a Radio Base Station (RBS). In some radio access networks the base station is e.g. called “NodeB” or “B node” or enhanced NodeB (eNB). A cell is a geographical area where radio coverage is provided by the equipment of a radio base station at a base station site. Each cell is identified by an identity within the local radio area, which may be broadcasted in the cell. The base stations communicate via an air interface with radio terminals within range of the base stations.
In some versions of the RAN, several base stations are typically connected, e.g. by landlines or microwave links, to a Radio Network Controller (RNC) or a Base Station Controller (BSC) or similar. The radio network controller or similar supervises and coordinates various activities of the plural base stations connected thereto. The radio network controllers are typically connected to one or more core networks.
For example, the General Packet Radio Service (GPRS) is a wireless communication system, which evolved from the GSM. The GSM EDGE Radio Access Network (GERAN) is a radio access network for enabling radio terminals to communicate with one or more core networks.
For example, the Universal Mobile Telecommunications System (UMTS) is a third generation wireless communication system, which evolved from the Global System for Mobile Communications (GSM), and is intended to provide improved mobile communication services based on Wideband Code Division Multiple Access (WCDMA) access technology.
Typically the Core Network (CN), to which the radio terminal communicates via the RAN, comprises a number of core network nodes.
One such core network node is the network access gateway node. The network access gateway node provides connectivity for the radio terminals of the communication network to one or more external Packet Data Networks (PDNs). A radio terminal may have simultaneous connectivity with more than one network gateway node for accessing multiple PDNs. The network access gateway node may e.g. be a Gateway GPRS Support Node (GGSN) or a PDN Gateway (PGW). Further properties and functions of a GGSN and a PGW will be discussed later.
Typically the network gateway provides PDN connectivity by creating a PDN-connection for a radio terminal to a PDN served by the network gateway. The PDN connection may be requested by the radio terminal, e.g. by sending a message to the network gateway, e.g. a PDN Connectivity Request message or similar.
An Access Point Name (APN) is used to identify the PDN to which the PDN-connection is to be created for the radio terminal. Thus, a PDN-connection is a connection for a radio terminal to a PDN identified by an APN. The APN may e.g. be provided to the network gateway by the radio terminal, e.g. in a message, sent when requesting the PDN connection, e.g. a PDN Connectivity Request message or similar. Alternatively the APN may e.g. be known by the network gateway (e.g. predefined in the network gateway) such that the network gateway knows that this APN is to be used for the particular radio terminal.
Thus, the APN identifies the PDN that a radio terminal wants to communicate with. In addition to identifying a PDN, an APN may also be used to define the type of service—e.g. connection to wireless application protocol (WAP) server, multimedia messaging service (MMS)—that is provided by the PDN. APN is e.g. used in 3GPP data access networks, e.g. the above mentioned GPRS and/or in the Evolved Packet Core (EPC).
The APN structure may e.g. comprise a network identifier and an operator identifier. The network identifier may e.g. define the external network to which the network gateway is connected. Optionally, it may also include the service requested by the radio terminal. The operator Identifier may define the specific operator's packet domain network in which the network gateway is located. This part of the APN may be optional. The operator Identifier may e.g. comprise the Mobile Country Code (MCC) and the Mobile Network Code (MNC) which together may uniquely identify a mobile network operator.
The use of PDNs, PDN connections and APNs is well known to those skilled in the art, especially within the framework of the 3GPP specifications, and it needs no further detailed explanations.
Now, when a PDN connection is to be established for a radio terminal to a specific PDN identified by an APN, then a network access gateway has to be selected to provide connectivity for the radio terminal to the PDN in question. This selection may be done by a mobility management node in the core network of the communication network, e.g. such as a Mobility Management Entity (MME) or similar. Properties and functions of a MME will be further discussed later.
Typically, the mobility management node selects a suitable network access gateway node among a number available access gateway nodes serving the APN in question based on the total load that each available access gateway node experience and a weight factor indicating the relative amount at which each access gateway node should be selected when PDN connections are created. Each access gateway may advertise the total load that it experience to the mobility management node. The load at node level is distinct from the load at APN level. The mobility management node may receive said weight factors from a Domain Name Server (DNS) or similar.
FIG. 2 is a schematic illustration of a MME performing a known selection scheme as the one now discussed, however selecting a Serving Gateway (SGW) instead of a PGW though the principle is the same. As can be seen in FIG. 2, the MME receives the load information from each available SGW (SGW1 20%, SGW2 60%, SGW3 80%). The MME receives the weight factor indicating the relative amount at which each access gateway node should be selected when PDN connections are created (SGW1 25, SGW2 25, SGW3 50). The MME then calculates the effective load for each SGW such that the load information is subtracted from 100% and the result is multiplied by the weight factor for the SGW in question. The MME then selects the SGWs based on the effective load for each SGW divided by the sum of all effective loads.
However, to improve the selection of a suitable network access gateway it has been suggested that each network access gateway that may be selected by the mobility management node should advertise the load per APN experienced by the access gateway in question. For example, the access gateway may advertise to the mobility management node that its capacity for handling PDN connections to an APN is at a certain level, e.g. that it handles PDN connections to the APN at a certain percentage of its capacity of handling PDN connections for that APN.
Some reasons for allowing the network access gateway (e.g. a PGW) that may be selected by the mobility management node to advertise the load condition at the APN level granularity may perhaps be described as follows:    1. To achieve evenly balanced network with the APN level granularity. The PGW may be configured to handle more than one APN in the network. In such a case, the PGW may be additionally configured to allocate different resources (e.g. based on the session license) for each of the configured APN, e.g. the PGW may be configured to handle “X” number of sessions for the “consumer” APN while “Y” number of session for the “corporate” APN. In this case, the load information with node level granularity is not sufficient to make better decision of the APN level load condition of the target PGW. And hence, it could result in a network where one PGW has more sessions for the “consumer” APN while another PGW has more sessions for the “corporate” APN. Thus, an evenly balanced network with APN level load granularity cannot be realized.    2. To ensure effective overload control in the network: If the distribution of sessions at APN level is uneven, then there is a high risk of overload of some PGWs as compared to other PGWs, e.g. the PGW handling sessions for “consumer” APN may have to handle more messages (e.g. generated due to mobility events resulting into change of ULI, RAT type, Serving GW, etc.) as compared to the PGW handling sessions for “stationary-machine” APN. This would result in some PGWs facing overload condition more often while the resources (e.g. handling of messages) of other PGWs remain underutilized. Thus, the situation leads to poor overload control of the network.    3. To ensure efficient node selection algorithm: Based on the node level load information, the source node (e.g. MME) may end-up selecting the PGW for a new session for the given APN. However, the selected PGW may reject the new session request if it is running at 100% load capacity. Or the new session request may be throttled by the source node based on the overload information of the APN for the given PGW. Thus, unless the source node takes the overload information into account while performing the node selection, the new session request may be denied (i.e. rejected by the selected PGW or throttled by the source node based on PGW's APN level overload information) while the other PGW may have the capacity to handle the same. Thus, the lack of APN level load information may result in inefficient node selection algorithm at the source node.
However, if load control information is provided at APN level, there will be some technical problems since the weight factor is defined at node level in the DNS:    1. How should the load control information at APN level be used? Should it be used separated from load control information at node level, or should it be used together with load control information at node level?    2. If load control information at APN level should be used separately, should it then be used together with the weight factors in the DNS or not?    3. If we use load control information at APN level together with the weight factors, then it will only work when the APN capacity of each PGW is in the same proportion of the total node capacity. For example, assume that PGW1 has a weight factor of 10 and that it supports two APNs, APN 1 with 1,000,000 PDN connections and APN2 with 2,000,000 PDN connections; while PGW2 has weight factor of 5, and if it also support APN1 and APN2, its APN1 capacity must be 500,000 PDN connections and APN2 capacity must be 1,000,000 PDN connections. With this precondition, the load sharing between PGW 1 and PGW 2 for every APN would work. But in reality, this is often not the case, in fact different PGWs may support a different set of APNs and may have different APN capacities.    4. If we use load control information at APN level without considering the weight factors, what will happen then? For example, assume that there are two PGWs, PGW1 has capacity with supporting 800,000 PDN connections for APN 1 and PGW 2 has capacity with supporting 200,000 PDN connections. The MME/SGSN should select PGW1 with 800,000/(800,000+200,000) and PGW 2 with 200,000/(800,000+200,000). This will achieve a type of load sharing among PGW 1 and PGW 2 for APN1. Now if we use load control information at APN level and we assume that PGW1 provides load control information for APN 1 with 50%, while PGW 2 provides load control information for APN 1 with 50%; then of 10 PDN connection creation requests, 5 would go to PGW 1 and 5 would go to PGW 2. This will eventually lead to an unbalanced load, considering the different capacity of PGW 1 and PGW 2 with respect to APN 1, which is against our initial purpose. After some time, PGW 1 may be loaded at 60%, while PGW2 will be loaded at 90%, but the selection proportions will be 60%/(60%+90%) and 90%/(60%+90%). This will not help at all to achieve load sharing, even at 99% load in PGW 2, in the end PGW 2 will be overloaded on APN1, (100% load) this is NOT what we want.
It seems that a direct use of load Control information at APN level will never achieve load sharing, since nodes with less capacity will quickly reach its limits and become overloaded.